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AMENDMENTS TO THE DRAWINGS 

Please find attached a Replacement Sheet of Figure 10 which has been 
amended to remove all language and markings to the right of the large box identified as 
service consumer 1 000. 
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REMARKS 

Claims 1-30 were pending at tiie time of the last Office Action. Applicant has 
amended claims 1 and 10, and canceled claims 3, 4, 7, 8, and 23-30. No new claims 
have been presented. Thus, claims 1, 2, 5, 6, and 9-22 are cun-ently pending. 

The Examiner has objected to claims 1 and 10 because of informalities. 
Applicant has amended the claims to address the Examiner's concerns. 

The Examiner has rejected claim 1 under 35 U.S.C. § 112, first paragraph, as 
failing to comply with the written description requirement and objected to the 
amendment of May 5, 2009. Applicant respectfully traverses this rejection. The 
Examiner indicates that she "did not find that the application was provided with access 
to an indication of the established limit." (Office Action, Sept. 22, 2009, p. 4.) 
Applicant's summary states 'The runtime environment makes the limit available to 
applications so that a correctly behaving application can know and abide by their limit." 
(Applicant's Specification, ^ 0009.) Making something available to an application clearly 
provides support for providing access to that something. Moreover, claim 1 as originally 
filed stated "providing the application with access to the established limit." 

The Examiner has rejected under 35 U.S.C. § 102(e) as being anticipated claims 
1, 5, 6, 10, 11, 13-15, and 17-22 based on McCorkendale and under 35 U.S.C. § 103(a) 
claims 2 and 12 based on McCorkendale and Davis and claims 9 and 15 based on 
McCorkendale and Choate. Applicant respectfully traverses these rejections. 

McCorkendale ("McC") allows a software developer to obtain a certification for 
software from a certifying authority. When a client attempts to execute the software, the 
client verifies the certification and sends a request to an execution authority requesting 
whether the software can be executed. The execution authority may permit or deny 
execution based on, for example, the number of execution requests that have been 
received from clients. 
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Claim 1 recites "wlien installing an application, establishing a limit on services of 
a service provider that the application is authorized to use." In rejecting claim 1 , the 
Examiner relies on paragraph 0056 of McC as describing to "when installing an 
application." Pargaraph 0056 describes installing of McC "software" on a client. The 
Examiner also relies on McC's "certifying authority" as corresponding to the claimed 
"service provider" and "the request to certify the software" as con-esponding to the 
claimed "service." (Office Action, Sept. 22, 2009, pp. 5-6.) 

Given this correspondence, McC does not meet the above-quoted language of 
claim 1 . McC's software does not request any services of the "certifying authority." 
McC makes it clear that the certifying authority receives a request from the "software 
developer" of the software. (McC, H 0037.) There is nothing in McC to suggest that the 
certifying authority receives any requests for service from the software itself. Moreover, 
McC's software also does not request the execution authority for any services. Rather, 
McC's gatekeeper module that uses "status information provided by the execution 
authority 118 via an execution authority client module 616 to determine whether to 
permit or deny the execution of software." (McC, H 0059.) Thus, it is McC's execution 
authority client module" that requests from the execution authority information on 
whether the software should be permitted or denied execution. 

The Examiner relies on McC's "trust levels" as corresponding to the claimed 
"limit" because the trust levels indicate thresholds of execution frequency. Whenever 
McC's execution authority receives a request for execution, the execution authority 
either permits or denies the request for execution based on whether a threshold is 

exceeded. Claim 1 recites "providing the application with access to an indication of the 
established limit." McC does not suggest that the software is provided with access to 
either the trust levels or the thresholds. 

Moreover, claim 1 makes it clear that the established limit allows the application 
"to not exceed the established limit." The Examiner believes that McC's denial of an 
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execution request corresponds to the claimed "providing ... an indication of the 
established limit." IVIcC's software is never informed when the "threshold" execution 
request is denied. McC's software is simply not permitted to execute. Thus, McC's 
software cannot use any threshold "to not exceed the established limit" as recited by 
claim 1. 

Independent claims 1 and 10 recite "under control of a runtime environment [of 
the consumer system]," ... determining whether the request would exceed the 
established limit [or misbehaving]" and "when it is determined that the request would 
exceed the established limit [or that the application is misbehaving], notifying the service 
provider that the application is misbehaving." It is not clear to applicant what the 
Examiner could possibly think corresponds to a runtime environment of the consumer 
system notifying a service provider when the established limit is exceeded. As 
discussed above, McC's software (or even client that executes the software) does not 
communicate with the certifying authority (which the Examiner believes corresponds to 
the claimed service provider). In addition, it is McC's execution authority that informs 
McC's client when execution is denied as a result of threshold being exceeded. Thus, it 
would make no sense for McC's client to then notify the execution authority that the 
software is misbehaving because the execution authority already knows that the 
threshold has been exceeded. 

Independent claim 17 recites "when service consumers detemiine that the 
application is misbehaving, receiving notification of the misbehavior from the service 
consumers." McC's clients do not determine whether the software is misbehaving and 
then notify the certifying authority or the execution authority of such misbehavior. 
Rather, McC's clients simply request whether to perniit execution of the software. 
McC's clients rely on the execution authority to determine whether a threshold number 
of requests for execution has been exceeded. 



41826-8001.USO0/LEGAL17107O81.1 



14 



Application No. 10/789,805 



Docket No.: 41 8268001 US 



Based upon the above amendments and remarks, applicant respectfully requests 
reconsideration of this application and its early allowance. If the Examiner has any 
questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-8548. 



Please charge any deficiency in fees or credit any overpayment to our Deposit 
Account No. 50-0665, under Order No. 41 8268001 US from which the undersigned is 
authorized to draw. 



Respectfully submitted, 

Maurice J. Pirio 

Registration No.: 33,273 
PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 981 1 1 -1 247 
(206) 359-8548 
(206) 359-9000 (Fax) 
Attorney for Applicant 



Dated: \t'lH'0'\ 
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